HDFS-16749. RBF: Gets the wrong directory information from Trash#6317
HDFS-16749. RBF: Gets the wrong directory information from Trash#6317LiuGuH wants to merge 3 commits intoapache:trunkfrom
Conversation
…rvice's trash path is not exists
|
@LiuGuH Thank you for your contribution! Could you please provide more details about your proposed modification? |
| // Client user see global trash view, wo should see all three mount point. | ||
| FileStatus[] fileStatuses = fs.listStatus(new Path("/user/test-trash/.Trash/Current/")); | ||
| assertEquals(3, fileStatuses.length); | ||
| assertEquals(2, fileStatuses.length); |
There was a problem hiding this comment.
Why does the size change?
There was a problem hiding this comment.
I add description in Description of PR. Thanks
There was a problem hiding this comment.
I modified the description and let's wait for other partners' suggestions. My personal suggestion is that we'd better solve the issue with smaller changes. (#5039)
There was a problem hiding this comment.
With #5039 , it will lead to user will not see any other nameservices trash path expect where the user home is mounted nameservices. It will break https://issues.apache.org/jira/browse/HDFS-16024 purpose.
|
💔 -1 overall
This message was automatically generated. |
|
@zhangxiping1 I see that you created HDFS-16749, pr #5039, and @LiuGuH also submitted a PR. Can we compare and explain the difference between the two prs? |
|
💔 -1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
|
Thanks @LiuGuH for your works.
I am confused why it returns wrong subdirs now? Thanks. |
|
getListing can be separated into two parts subtractTrashCurrentPath("/user/test-user/.Trash/Current") will get "" as moint point in default nameservices ns0, then construct monit point (2) subclusterResolver.getMountPoints(src) and then it be display getMountPoints is necessary because we will not see all subtrash dirs without it. My way of dealing with it is that for every child path,found its mount point ,and getFileInfo with it . If it is really exits, display it. @Hexiaoqiao @slfan1989 |
|
I think this PR is based on HDFS-17263, but we found that it introduced another bug, which was filed as HDFS-17842. In our environment, we reverted HDFS-17263 and have backported #5039 instead for now. |
|
We're closing this stale PR because it has been open for 100 days with no activity. This isn't a judgement on the merit of the PR in any way. It's just a way of keeping the PR queue manageable. |
Description of PR
As described in HDFS-16749.
Purpose :[RBF] Fix ls user trash path returns mountpoint path that real nameservice's trash path is not exists
There are two nameservices ns0 ns1, and ns0 is the default nameservice.
(1) Add moutTable
(2) add file
(3) mv files to trash
(4) client via DFSRouter: hdfs dfs -ls /user/test-user/.Trash/Current ,this will return
So, this PR is for this purpose, if a namservice that mount point dir in trash is not really exists, it should be not display in user trash view via DFSRouter